Method for functional verification of an integrated circuit model in order to create a verification platform, equipment emulator and verification platform

ABSTRACT

The present invention concerns a method for the functional verification of a software model ( 40 ) of an integrated circuit on demand (ASIC), in a low-level language (for example of the HDL type), which separately handles the creation of the model and the debugging of the functional verification tests to be applied to the model of the circuit in order to create a verification platform, comprising the following two steps:  
     creation of an autonomous circuit emulator ( 1 ), obtained by replacing the model in a low level (HDL-type) language physically describing the circuit under design to be validated with a high level (for example C++) abstract description generating response data structures in accordance with the functional specification ( 20 ) of the design as a function of the stimuli received, this mode being called the “transmission mode”;  
     integration of the software model ( 40 ) in low level (HDL-type) language of the circuit resulting from the design into a verification platform, and creation of the connection of the previously validated autonomous circuit emulator ( 1 ), in parallel, to the interfaces of the software model ( 40 ) of the circuit, and of the connection of an environment emulator ( 11, 21, 22 ); and  
     utilization of this platform as a reference for the validation of the response data transmitted by the software model ( 40 ) of the circuit, this mode being called the “verification mode.”

[0001] The present invention concerns a method for the functionalverification of a software model of an integrated circuit forconstituting a verification platform, and the verification platform thuscreated.

[0002] The invention is applied during the verification phase of thedesign of particular specifications of an integrated circuit that meetsthe needs of an industrial user, usually called an ASIC (ApplicationSpecific Integrated Circuit), and also in the checkout phase of thesystem constituted by the ASIC physical component and the applicationprogram executed by the ASIC physical component.

[0003] In the integrated circuit field, there are two types of circuits,the so-called conventional circuits and the so-called specific circuits,called ASICs. Manufacturers of conventional integrated circuits havestandard circuit catalogs wherein the references each designate aparticular standardized function. For specific applications, industrialusers of integrated circuits prefer to have specific circuits developed,known as ASICs.

[0004] The various stages in the development of ASICs are the following:

[0005] definition of a functional specification,

[0006] modeling (defined below) of the ASIC in an HDL-type hardwaredescription language and functional verification of the designassociated with this modeling,

[0007] technological production by the integrated circuit manufacturer,and

[0008] hardware debugging of the circuit.

[0009] Functional specification is defined as the generation ofdocuments describing the functionalities covered by the ASIC.

[0010] It includes:

[0011] the system level specifications, describing:

[0012] the functional visibility of the registers of the ASIC;

[0013] the coherence protocol that ensures the integrity of the data, inthe case of a system with shared memory,

[0014] the specifications of the external interfaces of the components,

[0015] and the specifications describing the choice of implementation ofthe ASIC.

[0016] The HDL-type modeling of the ASIC consists in the description ofBoolean logic equations that express its behavior in accordance with itsspecification. The HDL-type language used is a language dedicated to thedescription of the hardware objects of the integrated circuit(Hardware). It contains the primitives for describing the componentswith their interface signals as well as storage elements such asregisters or memories.

[0017] The HDL-type description level serves as an entry point into theautomatic generation process, resulting in the provision of masks forthe technological processes for manufacturing the circuit.

[0018] The purpose of the functional verification of the design of theASIC is to verify the compliance of the behavior of the HDL-type modelof the ASIC with its functional specification before beginning thetechnological process.

[0019] Once the logic of the ASIC is stabilized, a quasi-automaticprocess applied to the HDLtype description of the ASIC makes it possibleto generate a list of the physical cells constituting the ASIC and togenerate the masks delivered to the foundry (ASIC manufacturer) for themanufacture of the circuit.

[0020] The technological production of the circuit is the chemicalprocess that makes it possible, using masks, to produce physical samplesof the circuits.

[0021] Non-functional tests are applied after manufacturing to verifythat the technological process has gone well and to select samples thatare good candidates for mounting in packages for the next validationphase.

[0022] Hardware debugging is the first phase in the validation of ASICsin their real system environment after the samples are mounted inpackages and connected to cards.

[0023] During the manufacturing stage, the ASIC manufacturer is unableto verify that the functional model of the ASIC provided by theindustrial user does not include any design errors. It can only confirmthe silicon chips compliance with the functional diagram requested.

[0024] One of the objects of the invention is to allow the industrialuser of the ASIC, prior to the physical production of the circuit, toverify the exactitude of the functional model he is going to provide tothe foundry (ASIC manufacturer).

[0025] Given the high cost of designing ASICs, it is necessary tovalidate the theoretical diagram resulting from the functionalspecification as completely as possible in order to eliminate anyremaining errors before beginning the preparation of the production fileof the ASIC for the foundry. That is why the description level of themodel of the ASIC is used for the functional verification of the designof the ASIC prior to starting the technological production process. Thepurpose of the verification is to verify the compliance of the behaviorof the HDL-type model of the ASIC with its functional specification.

[0026] With the increasing complexity of ASICs linked to their highdegree of integration and the high cost of manufacturing them, thefunctional verification makes up a prominent part (more than 60%) of thedesign phase of the circuit, which will tend to increase even moresubstantially in the years to come.

[0027] Hence the need to have a solid functional verificationmethodology.

[0028] It is within this context that one of the advantages of theproposed invention lies.

[0029] When samples of the ASIC physical component have been produced,the industrial user validates the functionality of the system consistingof the ASIC physical component and application program executed by theASIC and verifies that they comply with the specifications of thesystem. During this phase, the ASICs, mounted in their packages, areconnected, on their card, to their real system environment so as toconstitute a validation platform.

[0030] The proposed invention can also be applied in this phase.

[0031] In order to functionally verify the various parts constitutingthe model of the ASIC, such as the arithmetic unit, memories, counters,combinational logic, router with cache, and other elements, it ispossible to activate them separately, insofar as each of them isdirectly accessible via the simulated input/outputs of the ASIC andsufficiently independent of the others. One then verifies that the partin question conforms to a logical functional model defined in thespecifications. It is also necessary to verify the interoperation of thevarious parts, by simultaneously activating several of these parts. Inparticular, it is necessary to perform combinational tests between theparts, in order to try to verify the absence of any configurations ofstates of the various respective parts that were not planned during thedesign of the functional model, and that could result in defectiveoperation, for example a mutual inhibition between two parts. It is easyto understand that the number of combinational tests increases muchfaster than the number of circuits or transistors in the ASIC. Inaddition, the presence of memories in the ASIC that can control some ofits circuits results in the fact that the global state of the variousoutputs, for inputs having the same global state at a given instant,depends on the history of the progression of the previous input states.

[0032] The debugging of the programming of functional tests is long andexpensive. In practice, this debugging is done using the model of theASIC. In other words, as soon as the model is designed, it is possibleto try to detect the following two types of errors: residual errors inthe specifications, and errors or omissions in the programs for thefunctional validation of the ASIC or in the application programs. Thisaccumulation of tasks, each of which reacts to the others, is obviouslydifficult to manage, and it entails costs and delays.

[0033] The present invention seeks to limit one or more of thesedisadvantages.

[0034] To this end, the invention concerns a method for the functionalverification of a software model of an integrated circuit on demand(ASIC), in a low-level language (for example of the HDL type), whichseparately handles the generation of the model and the debugging of thefunctional verification tests to be applied to the model of the circuitfor constituting a verification platform, comprising the following twosteps:

[0035] creation of an autonomous circuit emulator, obtained by replacingthe model in a low level (HDL-type) language physically describing thecircuit under design to be validated with a high level (for example C⁺⁺)abstract description generating response data structures in accordancewith the functional specification of the project as a function of thestimuli received, this mode being called the “transmission mode.”

[0036] integration of the software model in low level (HDL-type)language of the circuit resulting from the design into the verificationplatform, and creation of the connection of the previously validatedautonomous simulation configuration, in parallel, to the interfaces ofthe software model of the circuit, and of the connection of anenvironment emulator; and

[0037] utilization of the platform as a reference for the validation ofthe response data transmitted by the software model of the circuit, thismode being called the “verification mode.”

[0038] The functionality validation program can thus be debugged inmasked time, in parallel with the generation of the production file forthe ASIC. Then, a model of the latter having been generated, one needonly have in memory the input sequence of the functionality validationtest, since the emulator represents the functional specification andprovides the output stimuli in response to this input sequence, as areference.

[0039] Thus, functionally, the emulator constitutes a sort of librarythat contains all of the possible output states of the model of the ASICpredicted based on the responses of the functional specification to allof the possible stimuli provided by an environment emulator. Theprovision of input stimuli by the environment emulator is equivalent toaddressing the contents of the library in order to select thecorresponding predicted output state or stimuli. This library couldtherefore be a simple memory, constituting a decision table containingall of the predicted output states, addressed in order to decide whetherone of its states is the right one. However, the memory size requiredwould generally be excessive, and it is therefore preferable to generatethe prediction of the output stimuli in real time, based on thefunctional specification.

[0040] It should be noted that the method of the invention is notlimited to purely digital ASICs, since it is possible to emulate analogcircuits, if necessary, using a digital computation unit and adigital/analog converter.

[0041] In one embodiment, a user generates, using a data processingsystem, the autonomous simulation configuration corresponding to thesoftware model of the ASIC using the functional specification,

[0042] the user writes, from the functional specification, and stores ina test platform for integrated circuit models, a program for testing themodel of the ASIC, comprising input stimuli sequences to be provided tothe software model of the ASIC, which the autonomous simulationconfiguration, based on the functional specification, corresponds tooutput stimuli sequences.

[0043] the user links together, and activates, the autonomous simulationconfiguration and the test platform, and

[0044] he observes the output stimuli of the HDL-type model of the ASICin order to functionally validate the system constituted by the softwaremodel of the ASIC circuit and the validation test program, and thusvalidates the software module with respect to the functionalspecification.

[0045] Advantageously, the autonomous simulation configurationcommunicates with the user to control the activation of previouslycreated and stored models of input stimuli sequences defined in a highlevel programming language, and controls the activation of associatedprograms for the progressive validation of test sequences determinedfrom the models.

[0046] Thanks to the modularity of the system and the progressivity ofthe debugging, the user can thus rely, at first, on existing functionalvalidation test models, theoretically debugged, which he adds to oradapts to the particular case of the ASIC.

[0047] The user can write and provide the functional specification in alow level programming language, specifying functional models ofcircuits.

[0048] He can also, in a mixed mode, provide the functionalspecification in the form of a program in low level language, of (HDLtype) functional models of circuits, and of a program in high levellanguage of (symbolic (C++)) functional models of circuits, and controlthe autonomous simulation configuration (1) so as to perform aco-simulation by synchronizing the execution of the two specificationprograms.

[0049] The various parts of the functional specification can thus bewritten in the language that works best and that, in particular, avoidswasting any time in defining output stimuli.

[0050] Advantageously, the test platform verifies that the responses ofthe software model of the ASIC are within response time ranges specifiedin the functional specification.

[0051] The invention also concerns a verification platform for asoftware model of an integrated circuit on demand, characterized in thatit comprises data processing means that allow a client to select testmodels producing input stimuli for the ASIC, these processing meansbeing designed to read functional specification elements of the ASIC andcomprising programs designed to generate a functional validation testprogram constituted by output stimuli, from the input stimuli and thefunctional specification elements.

[0052] Advantageously, the verification platform comprises a library offunctional models of circuit blocks for ASICs and means for selectingmodels through a definition file of the configuration, in order tocreate a model corresponding to the functional specification of the ASICthat is integrated into the definition of its environment.

[0053] There may also be, in a link connecting it to the client, twoserial programming language adaptation circuits, designed to transformcommands in a high level language (C++), used by the client, intocommands in a low level language (of the HDL type) that can be used bythe model of the ASIC, and respectively, to transform the commands in alow level language back into commands in a high level language.

[0054] Advantageously, the verification platform includes means forexecuting its operations at the same time as the simulation, which itcan interrupt upon detection of an error, at the very moment the errorappears.

[0055] According to another characteristic, the functional specificationelements are constituted by a truth table or behavior tablecorresponding to the functions of the various parts or variousfunctional circuit elements of the software model of the ASIC, and thepropagation delay ranges to be respected between each input and eachoutput.

[0056] According to another characteristic, the verification platformhas a cache memory for storing the blocks used by the nodes according totheir addresses, and means for managing, for an address used by one ormore nodes, a presence vector with one presence indicator per node.

[0057] According to another characteristic, the programs areobject-oriented and the emulator is structured as a set of classes thatmakes it possible to manage a collection of execution hypotheses for atransaction in a memory block of the software model, and also to managetransactions that are colliding, i.e., using the same memory block.

[0058] According to another characteristic, the algorithms of theprograms of the emulator perform the following functions: generatingpredictions, eliminating predictions, readjusting incorrect predictions,reducing the number of valid hypotheses, and terminating collisions.

[0059] According to another characteristic, the verification platform isused as an emulator of a router circuit, a circuit with cache, or arouter circuit with cache.

[0060] According to another characteristic, the verification platformmakes it possible to test a software model of an integrated circuit ondemand (ASIC), characterized in that it comprises an ASIC emulator forcontrolling a comparator provided for receiving values generated by thesoftware model of the ASIC circuit tested, upon reception of stimulisent by at least one stimuli generating circuit storing the testprogram, an interface for translating the stimuli from an advancedlanguage into a low level language corresponding to that of the softwaremodel, and means for validating the verification in case of thedetection of a collision by the comparator.

[0061] In one embodiment, the means for selecting the response tostimuli that depend on the composition of the circuits tested areconstituted by a model generated using means for selecting functionalmodels from a library, which associates with each of the models theresponses to a given stimulus, the model corresponding to thecomposition of the circuit to be tested.

[0062] The platform can include means for storing the responses thusselected in order to create a test model to be applied to the circuittested upon reception of stimuli.

[0063] According to another characteristic, each transaction isconstituted, at the level of each interface, by a request packet and oneor more associated response packets, wherein the values of theparameters and/or the transmission time constraints of the packets canbe forced from the functional test program executed by the emulator ofthe environment, which appropriately translates all of these parametersduring the transmission of the packets to the terminals of the softwaremodel of the project.

[0064] According to another characteristic, the generation ofpredictions is performed by the emulator of the circuit without havingto obtain additional information on the internal operation of thecircuit under design.

[0065] The invention will be better understood with the help of thefollowing description of an embodiment of the invention and animplementation of the method of the invention, in reference to theattached drawing, in which:

[0066]FIG. 1 is a functional diagram representing an emulator of an ASICintegrated circuit, represented with the management of an interface inan environment emulator that can include one or several interfaces,

[0067]FIG. 2 represents the same emulator, logically connected inparallel to the software model of the ASIC circuit to be tested, oremulator of the circuit under design in the transmission mode,represented with the management of an interface in an environmentemulator that can include one or several interfaces,

[0068]FIG. 3 is a variant of FIG. 2 applied to a model of a circuit withtwo nodes, and

[0069]FIG. 4 represents the internal architecture of a verifier.

[0070] Before describing the invention, it is necessary, in order tomake it clearly understood, to establish a certain number of definitionsused below.

[0071] An emulator is a program or a device that makes it possible toreproduce in its external interfaces the same functioning as thecircuit(s) or HDL-type model(s) of the circuit(s) for which itsubstitutes.

[0072] In this document, the invention is applied to the case of anintegrated circuit of the router-with-cache type, because it isrecognized as being the most complex case. Hereinafter, the word ROUTERdesignates:

[0073] either the HDL type model of the circuit under design,

[0074] or the emulator of the circuit under design (“Design”) intransmission mode.

[0075] Object programming makes it possible to structure the emulator ofthe ROUTER as a set of specialized classes, and to simplify theoperation by localizing and specializing these operations to eachinstance of each class, as will be seen below.

[0076] In the context of the software simulation (“Software”), theverification platform is constituted by all of the stimuli generatingmodels and the observation models in the interfaces of the circuit underdevelopment or design (“Design”) to be validated. These observationmodels constitute an emulator of the environment of the circuit underdesign (“Design”).

[0077] The verification methodology of the platform of the inventionalso makes use of an emulator of the design (“Design”), which canfunction in two modes:

[0078] The Checker mode (“Checker”), in which the emulator of thecircuit under design (“Design”) serves as a reference for the validationof the responses from the circuit under design (“Design”) as a functionof the input stimuli applied by the environment emulator, or theresponses from the emulator of the circuit under design in thetransmitter mode.

[0079] The transmission mode, in which the emulator of the circuit underdesign (“Design”) substitutes for the design (“Design”) itself inautonomous simulation configurations for the debugging of theverification platform, without having to use the HDL-type model of thedesign (“Design”).

[0080] The set of emulators (circuit emulator and environment emulator)constituting the verification platform are object models written in C⁺⁺,connected to the interfaces of the model in a low level HDL-typelanguage of the circuit under design (“Design”) via HDL-type interfaceadaptors. The degree of use of the advanced language relative to thedegree of use of the low level HDL-type language varies depending on howfar the debugging of the emulators has progressed.

[0081] In general, one begins with a functional specification of acircuit containing a majority of C⁺⁺ language and only a few interfacesin an HDL-type language, and ends with a software model comprising amajority of low level HDL-type language and a few interfaces in C⁺⁺. Theevolution of the software model in HDL-type language of the circuitunder development takes place progressively, using debugged intermediatemodels containing a more balanced proportion of advanced languagerelative to the proportion of HDL-type language.

[0082] In the interface adapters, the C⁺⁺/HDL exchanges are abstractedinto events. The events keep track of the arbitrary exchanges of datacontained in the packets as well as the changes in the values of thecontrol signals. The packet is the atomic operation granularity of theabstract C⁺⁺ models belonging to the description level (or so-calledprotocol) of the interfaces.

[0083] In the checker mode (“Checker”), the emulator of the circuitunder design (“Design”) performs its checks in real time, which meansthat its operations are executed at the same time as the simulation,which it can interrupt upon detection of an error, at the very moment itappears. This characteristic, which is advantageous from an operationalpoint of view, makes it possible to avoid generating trace files duringnormal operation and to generate the information required for thediagnosis when there is an error, thus limiting the complexity of thepost-processing.

[0084] In the checker mode (“Checker”), the emulator of the circuitunder design (“Design”) can build its checks simply on the basis of thesystem-level functional specifications, without obtaining any additionalinformation on the internal operation of the circuit under design(“Design”). This remarkable property can be applied in two differenttypes of contexts:

[0085] The C⁺⁺/HDL simulation of the circuit under design (“Design”), inwhich the emulator of the circuit under design (“Design”) is connectedto all of the interfaces of the software model in low-level HDL-typelanguage of the circuit under design “(“Design”), through which itobtains the packet exchanges of the observation models via the interfaceadapters.

[0086] In C⁺⁺ execution alone, from traces obtained through theinterfaces of the software model of the circuit under design (“Design”),these traces possibly being reformatted into packet form before beingreused offline by the emulator of the circuit under design (“Design”).

[0087] The traces taken from the terminals of the circuit under design(“Design”) to be validated can be from different sources

[0088] In the context of the functional verification, they result fromthe storage of the packets exchanged during a prior simulation. Thetraces can exist either in text form or in the form of C⁺⁺ structuresknown as fibers, stored in a base.

[0089] In the context of the hardware debugging, they result from thesampling of the stimuli in the terminals of the physical sample of thecircuit. The stimuli abstracted into events are reformatted into packetform prior to being injected into the emulator of the design (“Design”)for diagnosis in an offline operation.

[0090] The functional tests control the parameterization of the packetstransmitted to the target design (“Design”) via its environment

[0091] In the context of the functional verification, the functionaltests rely on the application program interface (API) of the emulator ofthe environment of the circuit under design (“Design”) to be validated,in order to directly and precisely control the order of the transactionsto be transmitted to the design for execution. Each transaction isconstituted, at the level of each interface, by a request packet and oneor more associated response packets. The values of the parameters aswell as the time constraints for transmission of the packets can beforced from the tests. The emulator of the environment appropriatelytranslates all of these parameters during the transmission of thepackets to the terminals of the design (“Design”).

[0092] In this context, the functional tests also have the capability toforce, in each component of the system and in conformity with thecoherence protocol that ensures the integrity of the data in the system,the initial states of the addresses of the blocks accessed. Thiscapacity makes it possible to create, in a controlled manner, highlydiversified and complex coherence situations, without having toreconstruct an execution history that can result in these situations.

[0093] In the context of the hardware debugging, the execution of thefunctional tests is done in a real situation in the processors of thesystem, which includes the physical samples of the circuit to bevalidated. The functional tests describe programs translated into a setof instructions to be executed by the processors of the system, whichtranslate them themselves, if necessary, into transactions addressed tothe entire system.

[0094] In this context, the address spaces are typed. No direct forcingof the format of the transactions or the state of the blocks accessed ispossible.

[0095] Because of their different natures, it is impossible to rerun, ina real situation on the physical samples in the debugging context, thefunctional tests previously developed in the context of the functionalverification and applied via the environment emulator to the HDL-typemodel of the circuit under design (“Design”) in order to verify itsdesign prior to its physical production.

[0096] In FIG. 1, the reference 1 designates an integrated circuitemulator that can be used, in particular, for integrated circuits underdesign that must be produced on demand, called ASICs. The inventionapplies to all types of integrated circuits, for example a simplemicrocomputer type circuit or a complex system, such as for example amultinode coherent memory system. The memory nodes (Node 1-Node n) areinterconnected by the integrated circuit under design. A multimodesystem can be, for example, a set of integrated circuit cards comprisingmultiprocessors and/or input/outputs with a cache memory forming aplurality of communication nodes containing memories, wherein the nodescan transmit simultaneous requests to addresses in shared memory. Thephysical ASIC integrated circuit is absent from FIG. 1, and a softwaremodel of this circuit under design in a low level HDL-type language hasthe reference 40 in FIG. 2. The emulator 1 communicates with one or morenodes (Node 1-Node n). Each node can communicate with a client station50, or all of the nodes can communicate with one and the same clientstation 50. The emulator 1 is built around a data processing system 10such as a computer, which receives in memory 2 functional specificationdata 20 in the high level language, for example C⁺⁺, of the model 40 ofthe ASIC of the design to be produced in HDL-type language. The data 20define the responses that the ASIC under design must present to itsoutputs, upon successive states presented to its inputs. A local accessbus or communication means 1B with direct access to the emulator 1 isprovided here for managing it.

[0097] Generally, as mentioned above, the functional specification data20 determine that the ASIC under design to be defined by its HDL-typemodel presents, at a given instant, a given output state that is afunction of the current input state that is imposed on it, and afunction of the states of its possible “internal” memories (EMI), whichusually exist in ASICs. The term internal memory designates memorieswhose contents, whether or not they are readable from outside the ASIC40, act on the states of other logic or sequential circuits of the ASIC40. The states of the memories generally depend on the prior inputstates of the ASIC, that is, on the history of the input stimulisequences, and are stored in a memory 962 and in the core 961 of theemulator.

[0098] The emulator 1 generally includes, in memory 9, software 90 foroperating on the functional specification data 20. The software 90includes programs for progressively generating and validating testsequences for the functional validation of the ASIC under design. Ateach step in a functional validation test sequence, the output vector orstate, determined as a function of a current input vector and thehistory, is stored and updated in memory 91. This storage can affect thestate of the internal memories (EMI) of the ASIC under design, which inpractice is necessary at each step in order to calculate the successivecurrent output vectors, and above all, it can affect the evolution ofthe states of the internal memories of the ASIC as a function of thesuccessive input vectors, representing the effects of the history.

[0099] There is therefore a double “modulation” as opposed to a singleinput/output bijection.

[0100] In essence, on the one hand, different input vectors applied atdistinct instants in a stimuli sequence can have effects that“converge,” that is. That correspond to the same output vector, due tothe effect of the states of the internal memories.

[0101] On the other hand, identical input vectors applied at distinctinstants in a stimuli sequence can have effects that “diverge,”producing different output vectors, due to the effect of the states ofthe internal memories.

[0102] The functional specification defined by the data 20 can specify atruth table or behavior table corresponding to the functions of thevarious parts or various functional circuit elements of the HDL-typemodel 40 of the ASIC, but also propagation delay ranges to be respectedbetween each input and each output. The verification platform thusverifies that the responses of the ASIC are within the response timeranges specified in the functional specification 20.

[0103] The software 90 for generating functional validation testsequences thus interprets the specification data 20, taking into accountthe states of the internal memories (EMI) of the emulator, which are thecore 961 and the status memories 962 in the cache memory, in order toprovide the output vector associated with the input vector. The inputvector is provided by a user/operator who is debugging the test program(70).

[0104] The reference 30 designates a computer bus or a communicationmeans, connected either directly to a user's terminal or to a datatransmission network, which allows a user to dialog in client-servermode with the emulator 1 via a stimuli generating circuit 21,translating the commands transmitted, for example by a communicationinterface (“socket”), into stimuli, and an interface manager circuit 22,which manages the interfacing between the station 50 of at least oneclient and the emulator (1). This emulator functions as a user-emulator(50, 1) dialog interface, used in a first step illustrated by FIG. 1. Aswill be explained below in connection with FIG. 2, the circuit 21 servesto transmit the stimuli generated by the user client in the functionalvalidation phase, in order to apply them as input to the model 40 inHDL-type language of the ASIC and to the emulator 1, and the circuit 22is a monitor that manages the input and output interfaces between aclient station (50) and both the emulator 1 and the circuits 11 forconverting from an advanced language to the HDL-type language of thesoftware model 40 of the ASIC. These two circuits (21, 22) constitute,with the adapter 11, the environment emulator. A memory 210 of the testgenerating circuit 21 is provided for storing input stimuli sequences,the debugging and storage of the input sequences in their final formbeing, in this example, performed by the program.

[0105] The diagram in FIG. 1 thus illustrates an operating mode called“transmission,” in which the emulator 1, which receives through the bus30 commands from the user specifying input stimuli sequences, transmitsin return response stimuli representing the response provided for thesoftware model in HDL-type language 40 of the ASIC, thus making itpossible to debug the environment emulator 51.

[0106] The global test sequence program 51, stored on the client end,will temporarily pass through the memory 210 of a stimuli generatingcircuit 21.

[0107] In this example, as FIG. 1 illustrates, the emulator 1 isconnected by the node 122 to the circuits 21, 22 via two circuits 11 and12 for adapting between the two programming languages, these adaptationcircuits being serially connected and having mutually inverse adaptationfunctions. The adaptation circuit 11, connected directly to the circuits21 and 22, transforms stimuli (commands) coming from the latter, writtenin a high-level language, in this case the C⁺⁺ language, into alow-level language, in this case the HDL-type language directlyinterpretable by the software model 40 in HDL-type language of the ASICprovided, i.e., in this case commands created to be applied, understoodand executed by the latter. The stimuli provided by the circuit 21 inC⁺⁺ language are transformed into HDL-type language by an input/outputport 111 of the C⁺⁺/HDL adaptation circuit 11. They can be veryelementary binary commands, for example logic gates, or more elaboratecommands, for example for controlling a processor of the HDL-type model40 of the ASIC. The latter commands can, in particular, require a macrocommand, i.e. a sequence of elementary command stimuli.

[0108] The inverse HDUC⁺⁺ adaptation circuit 12, connected to the port111, serves as a front-end processor for the emulator 1, so that thelatter, which uses the C⁺⁺ language, can, after the adaptation of theHDL-type language into the C⁺⁺ language, operate on the stimuliinitially translated into the HDL-type language by the circuit 11. Thiscircuit 11 makes it possible to express the stimuli in their realoperating form, created to be effectively applied to the software model40 in HDL-type language of the ASIC of FIG. 2, from the port 111. Thisalso makes it possible to test the proper operation of the C⁺⁺/HDLadaptation circuit 11 for each of the input stimuli.

[0109] The C⁺⁺/HDL adaptation circuit 11 thus provides, through theinput/output port 111, physical and logical level commands or programsthat are directly compatible with the software model 40 in HDL-typelanguage of the ASIC provided. These commands are the translation ofsoftware commands or programs in a higher level, more abstract, andsymbolic language, constituting a descriptor specifying the physical andlogical commands actually to be applied. Thus, in this example, thegeneration of symbolic stimuli sequences of the test program 51, in alanguage at a higher level than the physical and logical level of themodel 40 of the ASIC, makes it possible to remain independent of thephysical characteristics and/or the internal programming language of theHDL-type software model 40 of the ASIC, and thus facilitates the writingof these sequences. As indicated, it is the C⁺⁺/HDL adaptation circuit11 which, in a subsequent stage of this writing of the sequences,performs the desired transposition for the practical execution of thesequences of the test program 51.

[0110] In the opposite direction, from the emulator 1 to the bus 30, thelanguage adaptation circuits 12 and 11 have the inverse functions ofthose respectively described; the circuit 12 transforms the datareceived from the emulator 1 formulated in high-level C⁺⁺ language intodata in a low-level, HDL type language. The circuit 11 transforms thesame data that were formulated in a low-level language, i.e. of the HDLtype, by the circuit 12 back into data in a high-level language, i.e.,C⁺⁺.

[0111] As indicated above, the HDL-type software model 40 of the ASIC,absent from FIG. 1, is functionally represented by the system referenced140, which is constituted by the emulator 1 with, in this case, theadaptation circuit 12 as a front-end processor, an input/output port 121of which receives the low-level commands from the port 111 and transmitsthem to the emulator 1 through an input/output port 122, after havingtransformed them back into a high-level language. In practice, in thiscase it is the same as that used by the stimuli generating circuit 21,i.e. the C⁺⁺ language, but the invention also applies in cases where thelanguage used by the circuit 21 would be, of course, advanced, butdifferent from C⁺⁺. Thus, the user can dialog with the emulator 1 usinga high-level language, C⁺⁺, the language adaptation circuits 11 and 12having effects that cancel each other out and are thus completelyfunctionally hidden from the user, as long as the circuit 11 does nothave any functional defects, as mentioned previously.

[0112] As indicated above, the system constituted by the emulator 1 andits language adapter 12 constitutes an emulator that conforms perfectlyto the software model 40 in HDL-type language of the ASIC, but thedebugging of these stimuli sequences is performed using the high-levellanguage, thus remaining independent of the hardware specificities ofthe ASIC and the specificities of low-level languages for describingintegrated circuits, such as the HDL-type language. This debugging alsomakes it possible to verify, in particular, that the adaptation circuit11, which is used in the configuration of FIG. 2, provides the desiredadaptation for each type of stimuli of the test program 70 debugged. Inother words, the debugging of the test program 70 is performed in thehigh-level language C⁺⁺, but it includes a verification of the properfunctioning of the “scale” (adaptation circuit 12), which makes itpossible to “lower” the test program 70 from the symbolic language C⁺⁺to the low-level HDL-type language that is directly usable by theHDL-type model 40 of the ASIC.

[0113] The functional validation test sequences are debugged by a userconnected to the bus 30 by sending the input stimuli and receiving inreturn reactions from the operating software 90 in memory 9, whichindicates any potential defects in the generation of the overall testsequence program, and allows them to be corrected. Once the functionalvalidation test sequences have been debugged, all of the latterconstituting the test program 51 are recopied into the operating memory210 of the stimuli generating circuit 21.

[0114]FIG. 2 illustrates a subsequent phase of operation called“verification,” in which a functional validation test is performed onthe software model 40 of the ASIC in HDL-type language. In this phase,under the control of the stimuli of the test program 51 transmitted bythe memory 210, the various input states submitted to the software modelof the ASIC are also submitted as input to the emulator 1, whichdynamically generates, through the program 90, the predictable outputsthat appear successively in the output 230 of the emulator 1, re-usingprecisely the same functional specification 20 used for the“transmission” mode. The outputs of the emulator 1 evolve in step withthe real state of the outputs of the software model 40 of the ASIC inHDL-type language, making it possible to detect any discordance of thedesired target operation defined by the emulator 1.

[0115] In FIG. 2, the emulator 1 dialogs directly with a stimuligenerating circuit 21 and an interface monitor circuit 22 for each modeof the software model, since the C⁺⁺/HDL language adaptation performedby the adaptation circuit 11 has been verified in accordance with thediagram of FIG. 1. The inverse adaptation circuit 12 is thereforeomitted. The software model 40 of the ASIC in HDL-type language istherefore connected to the port 111 of the adaptation circuit 11 (drawnin reverse) serving as a front-end language adaptation processor. Inother words, the software model 40 of the ASIC in HDL-type language ofFIG. 2 replaces the system 140 constituted, in FIG. 1, by the emulator 1with its front-end adaptation circuit 12. The emulator 1 of FIG. 2therefore serves to check the real responses from the software model 40of the ASIC in HDL-type language by comparing them to those provided bythe emulator 1.

[0116] The port 112 is represented here divided into an input port 112A,connected to the test stimuli generating circuit 21 by a link 25, and anoutput port 112B connected to a comparator 23. The HDL-type model of theASIC 40 thus has, for its environment, an interface 112A, 112B fordialog in the high-level language, in this case C⁺⁺, used by the othercircuits 1, 21, 22 and 23.

[0117] The emulator 1 is connected as an input to the link 25, hencedirectly in parallel to the input port 112A for receiving, like theHDL-type model 40 of the ASIC via the adaptation circuit 11, the stimulisequences stored in memory 210, which correspond to the validation testprogram 70 in high-level language, which has been debugged in accordancewith the diagram of FIG. 1. In response, the emulator 1 provides thecomparator 23 with an output state, stimuli, or vector, as a function ofthe specification data 20, which is considered to be the target, orreference, output state, associated with the input state. Of thepredictable output states, it is the one that is determined or selectedbased on the input state provided to the verifier 960. The role of theverifier 960 will be explained below.

[0118] The software model in HDL language of the ASIC also provides, onits end, an output state that is transformed by the adaptation circuit11 in order to be presented in the high-level language C⁺⁺, this outputbeing theoretically identical to the one provided by the emulator 1. Thecomparator circuit 23 has been drawn so as to illustrate the comparisonof the outputs it receives, and in reality, it is functionally part ofthe emulator 1. The comparator 23 compares the output states of theHDL-type model 40 of the ASIC received through the port 112B, and theoutput stimuli provided by the verifier 60 of the emulator 1, in orderto detect any possible discordance and indicate it to the client user.In such a case, this indicates a lack of compliance of the softwaremodel 40 in HDL-type language of the ASIC with the specification 20, dueto a design flaw or a functional error at the level of theASIC-model/test program system. The output from the comparator 23 fillsa file that records error notifications in case of an inconclusivecomparison. The interface monitor circuit 22 and the stimuli generatingcircuit 21 receive the outputs from the HDL-type model in order tofactor any prior responses into the generation of stimuli and generatetrace files for the generator 21.

[0119] As mentioned above, the client can, in a variant or complement,write and provide all or part of the functional specification 20 in theform of a program in a low-level language, as defined above, whichreplaces or complements a comparable high-level program. In the casewhere the functional specification 20 is thus defined overall in twolanguages that differ in terms of their levels or anothercharacteristic, the user client controls the emulator 1 so that the testgenerating software 90 provided for this purpose performs aco-simulation, or co-emulation, by synchronizing the execution of thetwo specification programs.

[0120]FIG. 3 uses the elements represented in FIG. 2, but with aduplication of the language adaptation circuit 11, 112, respectively,for a first and second node and circuits 21 ₁, 21 ₂, 22 ₁, 22 ₂, and ofthe interface bus 30 for linking with the user clients, for multi-node(Node 1, Node 2) and multi-user (Client 1, Client 2) operation.

[0121]FIG. 3 represents an embodiment of the verification platform ofthe invention which includes the prediction generation model, oremulator 1, constituting the verifier that makes it possible to verifythe compliance of the HDL-type model of the ASIC developed with thefunctional specification and with the tests developed for verifying thisfunctional specification.

[0122] In the remainder of the document, the word ROUTER designateseither the software model in HDL-type language of the circuit underdesign, which is a router circuit that allows the routing of informationin a multi-node system, or the emulator of this circuit in transmissionmode.

[0123] A transaction of the system is executed in the following way.

[0124] The execution context of the emulator of the ROUTER is amulti-node system with coherent memory, these nodes being interconnectedby the ROUTER. A multimode system can be, for example, a set ofintegrated circuit cards comprising multiprocessors and/or input/outputsforming a plurality of communication nodes containing memories, whereinthe nodes can transmit simultaneous requests to addresses in sharedmemory.

[0125] The components of a transaction are the following.

[0126] A node can transmit so-called primary requests of the read, writeor inhibit type. These requests will receive one or more so-calledprimary responses. The ROUTER, in order to process a primary requesttransmitted by a first node P, can be made to generate one or moreso-called secondary requests to nodes S that are distinct from the firstnode P. Each node S will transmit one or more so-called secondaryresponses. All of these secondary responses will be used by the ROUTERto transmit the primary response.

[0127] The combination {request and primary response(s); request(s) andsecondary response(s)} constitutes a transaction.

[0128] The nodes have a cache memory for storing the memory blocks used,which contain either addresses or data.

[0129] The ROUTER has a cache memory (called DIRECTORY in the remainderof the document) for storing the blocks used by the nodes according totheir addresses. For an address used by one or more nodes, a presencevector is managed with one presence indicator per node. This cachememory makes it possible to limit the generation of secondary requeststo the nodes that can be used for the execution of the transaction(example: an inhibition propagated to the nodes that have the validpresence indicator).

[0130] The ROUTER can be made to process several transactions related tothe same memory block. This set of transactions is called a collision.The ROUTER handles them serially. The order in which the ROUTER handlesthem is called the serialization order.

[0131] For each primary request, the ROUTER is made to determine thefinal state of the memory block.

[0132] [Case a]: If the determination of this final state by the ROUTERrequires one or more {request, secondary response(s)}, the transactionmoves into the critical section (until the secondary responses arereceived), visible to the emulator.

[0133] [Case b]: In the opposite case, the emulator only knows of theROUTER's decision through the primary responses.

[0134] The emulator's difficulty in monitoring the activity of theROUTER results from the fact that the transactions corresponding to thesecond case [Case b], have a serialization point that is not visible tothe emulator.

[0135] Conversely, the transactions corresponding to the first case[Case a] have a serialization point that is visible to the emulator, andthey offer the emulator an important aid in monitoring the activity ofthe ROUTER.

[0136] The emulator in verification mode will make predictions.

[0137] In order to monitor the activity of the ROUTER in case ofcollision, the emulator must predict all of the possible relevantserialization orders created by this collision.

[0138] The generation of predictions consists in the production, foreach case of serialization envisaged, profiles of the secondary requestsand primary and secondary responses that must appear in the interfacesof the ROUTER.

[0139] The observation of an output from the ROUTER [secondary request,primary response] is compared to the prediction profiles. If there is nocorrespondence, the prediction is rejected.

[0140] If there is no prediction that corresponds to the observation,the emulator indicates an error.

[0141] Object programming makes it possible to structure the emulator ofthe ROUTER as a set of specialized classes, and to simplify theoperation by localizing and specializing, these operations to eachinstance of each class.

[0142] The following classes are used by the invention:

[0143] The class “Txnld”.

[0144] An instance (T) of this class handles ensures the monitoring ofthe execution of a transaction.

[0145] This instance T manages a collection of execution hypotheses(which are instances of the class TxnldHypothesis).

[0146] An execution hypothesis is saved as long as the observations ofthe outputs from the ROUTER conform to the predictions made by thishypothesis.

[0147] The execution of this instance T is considered to be correct aslong as there is at least one dynamic hypothesis.

[0148] This instance T is in charge of verifying the end of execution ofthe transaction (that is, if there are dynamic hypothesis that haveobserved all the predicted outputs of the ROUTER).

[0149] The class “TxnldHypothesis”.

[0150] An instance (TH) of this class handles the monitoring of anexecution hypothesis of a transaction.

[0151] This instance (TH) manages an instance of the class Syst_Xaction.

[0152] This instance (TH) is in charge of verifying that theobservations of the outputs from the ROUTER conform to the predictionsof this hypothesis.

[0153] The instance (TH) is in charge of handling the responses to thesecondary requests.

[0154] The class “Syst_Xaction”.

[0155] An instance (SX) of this class stores the information related tothe primary request, and to the secondary request(s) predicted by theattached hypothesis. This instance (SX) also stores execution markersfor the transaction.

[0156] The class “CollisionScript”.

[0157] This instance (CS) also handles cases of non-collision (i.e., thecase of a current translation in another memory block).

[0158] For each transaction involved, an execution hypotheses of thistransaction is attached to the instance (CS).

[0159] The instance (CS) manages an ordered list of instances of theclass “CollisionElement.”

[0160] This ordering reflects the serialization of the collidingtransactions.

[0161] The class “CollisionElement”.

[0162] An instance (CE) of this class manages the execution state of anexecution hypothesis of a transaction in a collision context.

[0163] The main execution states are:

[0164] ASLEEP: no observation of outputs from the ROUTER has beenperformed for this hypothesis.

[0165] PREDICTED: all of the predictions to be used for monitoring thehypothesis have been generated.

[0166] WTSNOOP, WTCMP: the transaction is in the critical section,waiting for (a) secondary response(s).

[0167] WTTRANS: no observation of outputs from the ROUTER can take placefor this hypothesis.

[0168] COMPLETED: the transaction is terminated.

[0169] For the states ASLEEP and WTTRANS, no prediction has been made.

[0170] The state WTTRANS is reached for a hypothesis whose serializationmust wait for the end of the critical section of another transaction.

[0171] The instance (CE) also manages an instance of the class“DirectoryEntry.”

[0172] The class “DirectoryEntry”.

[0173] An instance (DE) of this class manages the state (ESI) of amemory block, as well as the presence vector of this block in theperipheral nodes of the ROUTER.

[0174] This information reflects what the ROUTER has for managing theblock.

[0175] Each subscript of the presence vector (or presence indicator)indicates:

[0176] either the certain presence of the block in the attached node;

[0177] or the potential presence of the block in the attached node;

[0178] In certain cases (for example the execution of certain types oftransactions in a collision context), the ROUTER can erase or maintain apresence indicator without indicating this event through specializedoutputs that can be observed by the emulator.

[0179] The class “transition”.

[0180] This class handles the activation of a transition related to anevent (EV) {primary request or secondary response in a critical sectioncontext} and to an instance DE.

[0181] The transition to be activated is searched for in a table(instance of the class TransitionTable).

[0182] This activation results in the updating of the instance (DE) andin the activation of an instance of the class “TransitionAction.”

[0183] The class “TransitionTable.”

[0184] This class generically describes all of the transitionsauthorized by the protocol.

[0185] For each state of an instance (DE), for each type of event EV, itspecifies how to update the instance DE and the instance of the class“TransitionAction” to be activated.

[0186] The class “TransitionAction.”

[0187] This class encompasses the various types of generic actions to beaccomplished following the reception of an event EV.

[0188] These actions use as parameters the primary request and thecontent of the associated instance DE.

[0189] These actions include, among other things:

[0190] the propagation of an inhibition to the nodes having the presenceindicator in the instance DE,

[0191] the propagation to the node holding the target memory block of areading or update of this block;

[0192] the propagation of a response to the node that initiated theprimary request.

[0193] The term “propagation” reflects the generation of the predictionsthat will be compared to the observations of the outputs from theROUTER.

[0194] The class “Directory.”

[0195] An instance (D) of this class manages the instances DE associatedwith the memory blocks present in the filters of the ROUTER.

[0196] An instance DE indicates a stable state of the block if notransaction is currently being executed in this block.

[0197] In the opposite case, the input DE stores the instances Tcurrently active in this block.

[0198] The next state of this instance DE is then currently evaluated inthe various instances CE/CS associated with these instances T.

[0199] The class “VerifierCore.”

[0200] An instance (VC) of this class manages all of the activity.

[0201] VC receives the stimuli (primary/secondary requests/responses),creates the instances T upon reception of the primary requests, submitsthe stimuli to these instances and destroys them at the end of thetransaction.

[0202] The algorithms of the ROUTER perform the following functions:

[0203] Prediction generation function:

[0204] Upon observation of a secondary request or primary response(transmitted by the router) related to a transaction t, all of thepertinent scripts (i.e., the various orders of serialization) activatethis transaction and those that collide are evaluated.

[0205] Prediction elimination function:

[0206] A prediction is eliminated (i.e. the instance CS of the classCollisionScript is destroyed) if, in this instance CS, the state of thetarget instance of the class “CollisionElement” is not compatible withthe observation, or if, in this instance CS, the prediction handled bythe target instance of the class “TxnldHypothesis” does not conform tothe observation (example: no conformity between the profile of theobservation and the prediction).

[0207] Incorrect prediction readjustment function:

[0208] In certain cases (the execution of certain types of transactionsin a collision context), the ROUTER can erase or maintain a presenceindicator in its cache memory (Directory) without indicating this eventthrough specialized outputs that can be observed by the emulator. Bydefault, the emulator of the ROUTER generates predictions with thepresence indicator erased.

[0209] If an observation shows that the opposite choice would be wiser,the instances of the class “CollisionScript” involved are re-evaluated,maintaining the presence bit in question.

[0210] Function for reducing the number of valid hypothesis:

[0211] In order to monitor a collision, the emulator of the ROUTER ismade to generate a number of instances of the class “CollisionScript,”which may become high.

[0212] Certain collision cases can produce the same observations for theserializations obtained by changing the order in which the transactionsinvolved are handled.

[0213] In order to limit the number of instances of the class“CollisionScript,” the emulator of the ROUTER detects in each instance“CollisionScript” the subsets of instances of “CollisionElement” in theCOMPLETED or PREDICTED state for which the attached instance DE has notchanged.

[0214] These subsets are re-ordered. The duplicates are eliminated.

[0215] Collision termination function:

[0216] The emulator of the ROUTER detects, in all of the instances ofthe class “CollisionScript” related to a collision, the situations inwhich the n first instances of the class “CollisionElements” are relatedto the same transactions and result in compatible states of the cachememory (Directory).

[0217] These instances of the class “CollisionElements” are thendestroyed, and the instance of the corresponding class “DirectoryEntry”in the Directory is updated.

[0218] The organization of the emulator thus defined makes it possibleto simplify the operation by localizing and specializing theseoperations to each instance of each class, to isolate a transaction or acollision, and to specialize the classes so as to make the operationsgeneric.

[0219] The isolation of a transaction or a collision is obtained throughthe fact that a transaction is modeled via an entry in the transactiontable. This entry consists in a pointer to an instance T of the classTxnld. This instance points to instances TH of the class“TxnldHypothesis.” Each instance TH points to an instance SX of theclass “Syst_Xaction,” to an instance CS of the class “CollisionScript,”and in this instance of the class “CollisionScript, to an instance CE ofthe class “CollisionElement.”

[0220] This instance CE points to an instance DE of the class“DirectoryEntry.”

[0221] The advantages of this organization are air tightness between theprocessing of the transactions and easy monitoring of a transaction or acollision (objects linked by pointing).

[0222] The air tightness between the processing of the transactionsensures a robustness of the processing relative to the load, easydebugging (a problem linked to the processing of a collision isindependent of the load and can therefore be analyzed by recreating thiscollision alone).

[0223] The easy monitoring of the operations simplifies the debuggingphases and the monitoring of the program.

[0224] The specialization of the classes and the genericity of theoperations are due to the fact that the classes “Transition,”“TransitionTable,” and “TransitionAction” are specialized in theprocessing of the transitions and independently handle a very large partof the protocol. They can be easily adapted to other protocols of theMESI type.

[0225] The classes “CollisionScript” and “CollisionElement” arespecialized in the processing of the serialization orders. The onlypieces of information manipulated are the possible states of thetransactions (final state of the predictable block, necessary criticalsection) and the states of the cache memory (Directory) produced by thetransitions. Algorithms for limiting the number of “CollisionScripts”that are independent of the protocol can be applied based on the finalstates provided by the transitions.

[0226] The classes “Txnld,” TxnldHypothesis, and “Syst_Xaction” arespecialized in the monitoring of the execution of a transaction (storageof the current secondary requests, various execution indicators,handling of the secondary responses) and in the comparison of theprofiles of the predictions and observations.

[0227] The classes “Directory” and “DirectoryEntry” are specialized inthe management of the cache memory.

[0228] All of the cache memory protocols can be easily integrated.

[0229]FIG. 4 represents the internal architecture of the verifier.

[0230] Each of the clients transmits, via call commands JCALL, requestsfor tests of the HDL-type model 40 of the ASIC circuit. These commandsare transmitted to the stimuli generator 21 and the interface monitor22, which sends them to the verifier circuit of the emulator 1 in orderto generate predictions of the responses of the model of the ASIC, andto the circuit 11 for converting from an advanced language in C⁺⁺ to alow level HDL-type language for describing the hardware of the ASICcircuit, and through these converters to the HDL-type model of the ASICcircuit.

[0231] The requests are received by the processing interfaces XSEqGen(FIG. 4) of the verifier 960 and are also used in the stimuli generatingcircuits 21, 22 to transmit and verify the request packets. Twoinstances are used for each interface of the verifier 60; a first, whichreceives the requests sent to the emulator 1, acts like a responder,while the other, which transmits the requests from the emulator, actslike a transmitter, but both are identical.

[0232] The verifier core 961 is the central component that generates thepredictions based on the addresses in the directory 962 (SF/ED) of thememory, the presence vector of the response stimuli, and the receivedpackets representing the input stimuli. The verification core 961 isorganized around classes instantiated in the form of objects. Theverifier core 961 stores configuration registers for routingnon-coherent requests, determining the location of the memory forcoherent requests, and managing the domains. The core of the verifierincludes a table 9610 for the transactions currently being used insidethe verifier. Each entry in the table points to an instance of the classTXNID, which represents the transmission of the transaction inside theverifier.

[0233] Each time a coherent input request is received by the verifier961, a temporary structure is created for predicting which transactionin the directory will be used as a block address and which ones will bethe predicted outputs from the model of the ASIC circuit under test tothe transmission circuit XSEqGen. This temporary structure is aninstance of the class “collision element.” The processing of atransaction always uses this structure, even if no collision withanother transaction is detected.

[0234] In order to execute the prediction, the entry in the directory(an instance of the class directory entry) used by this block is copiedand used by the instance collision element of the class“CollisionElement.” The prediction of the execution is processed throughthe use of instances of the classes “Transition” and “TransitionAction.”The instances of the classes “Transition” and “TransitionAction” arepart of the functional specification contained in the memory (2). Theinstances of this class are created at the time of the simulation andprovide methods that are a function of the generation of a statetransition and of the generation of requests sent or responses providedby the verifier. These methods are activated by the instances ofcollision elements of the class “CollisionElement.”

[0235] The operation of the core is based on the use of a certain numberof classes that are used to describe resources and to describe methodsused by the instantiations of this class in an object. This structure inthe form of classes makes it possible to create a verification platformthat is easily modified by instantiating new objects, thus making itpossible to describe new test procedures or new responses to stimulireceived through new functionalities added to the circuit. It is thuseasy to adapt the platform to new circuits developed.

[0236] It should be clear to the reader that when the term HDL orHDL-type model is used, it refers to a language for describing anintegrated circuit that is considered to be at the lowest level relativeto the so-called high-level C⁺⁺ language, but this should not beinterpreted as a limitation, as the invention also applies to any otherlanguage for describing an integrated circuit, such as for example VHDLor verilog or any other.

[0237] It is understood that the present invention can be implemented inother specific forms, without going beyond its scope of application asclaimed. Consequently, the present detailed description should beconsidered to be a simple illustration of a particular case within thecontext of the invention, and can therefore be modified without goingbeyond the scope defined by the attached claims.

1. Method for the functional verification of a software model (40) of anintegrated circuit on demand (ASIC), in a low-level language (forexample of the HDL type), which separately handles the generation of themodel and the debugging of the functional verification tests to beapplied to the model of the circuit for constituting a verificationplatform, comprising the following two steps: creation of an autonomouscircuit emulator (1), obtained by replacing the model in a low level(HDL-type) language physically describing the circuit under design to bevalidated with a high level (for example C++) abstract descriptiongenerating response data structures in accordance with the functionalspecification (20) of the project as a function of the stimuli received,this mode being called the “transmission mode.” integration of thesoftware model (40) in low level (HDL-type) language of the circuitresulting from the design into a verification platform, and creation ofthe connection of the previously validated autonomous circuit emulator(1), in parallel, to the interfaces of the software model (40) of thecircuit, and of the connection of an environment emulator (11, 21, 22);and utilization of this platform as a reference for the validation ofthe response data transmitted by the software model (40) of the circuit,this mode being called the “verification mode.
 2. Method according toclaim 1, wherein: a user generates, using a data processing system, theautonomous simulation configuration (1) corresponding to the softwaremodel (40) of the ASIC using the functional specification (20), the userwrites, from the functional specification (20), and stores in a testplatform (21, 22, 23) for integrated circuit models, a program (51) fortesting the model (40) of the ASIC, comprising input stimuli sequencesto be provided to the software model (40) of the ASIC, which theautonomous simulation configuration (1), based on the functionalspecification (20), corresponds to output stimuli sequences, the userlinks together, and activates, the autonomous simulation configuration(1) and the test platform (21, 22, 23), and he observes the outputstimuli of the HDL-type model (40) of the ASIC in order to functionallyvalidate the system constituted by the software model of the ASICcircuit and the validation test program (210), and thus validates thesoftware model (40) in comparison to the functional specification (20).3. Method according to either of claims 1 and 2, wherein the autonomousconfiguration (1) communicates with the user to control the activationof previously created and stored models of input stimuli sequencesdefined in a high-level programming language, and controls theactivation of associated programs (90) for the progressive validation oftest sequences determined from the models.
 4. Method according to any ofclaims 1 through 3, wherein the user writes and provides the functionalspecification (20) in a low-level programming language, specifyingfunctional models of circuits.
 5. Method according to any of claims 1through 4, wherein the user provides the functional specification (20),in the form of a program in a low level language of (HDL type)functional models of circuits, and a program in a high level language of(symbolic (C⁺⁺)) functional models of circuits, and he controls theautonomous simulation configuration (1) so as to perform a co-simulationby synchronizing the execution of the two specification programs. 6.Method according to any of claims 1 through 4, wherein the test platformverifies that the responses of the software model of the ASIC are withinresponse time ranges specified in the functional specification (20). 7.Verification platform for a software model of an integrated circuit ondemand (ASIC), characterized in that it comprises data processing meansthat allow a client to select test models producing input stimuli forthe ASIC, these processing means being designed to read functionalspecification elements (20) of the ASIC and comprising programs (90)designed to generate a functional validation test program (51)constituted by output stimuli, from the input stimuli and the functionalspecification elements (20).
 8. Verification platform according to claim7, comprising a library of functional models of circuit blocks for ASICsand means for selecting models through a definition file of theconfiguration, in order to create a model corresponding to thefunctional specification of the ASIC that is integrated into thedefinition of its environment.
 9. Verification platform according toeither of claims 7 and 8, wherein it is provided, in a link connectingit to the client, with two serial programming language adaptationcircuits (11, 12), designed to transform commands in a high levellanguage (C⁺⁺), used by the client, into commands in a low level (HDLtype) language that can be used by the model of the ASIC, andrespectively, to transform the commands in a low level language backinto commands in a high level language.
 10. Verification platformaccording to any of claims 7 through 9, characterized in that itincludes means (90, 10) for executing its operations at the same time asthe simulation, which it can interrupt upon detection of an error at thevery moment the error appears.
 11. Verification platform according toany of claims 7 through 10, characterized in that the functionalspecification elements (20) are constituted by a truth table or behaviortable corresponding to the functions of the various parts or variousfunctional circuit elements of the software model (40) of the ASIC, andthe propagation delay ranges to be respected between each input and eachoutput.
 12. Verification platform according to any of claims 7 through11, characterized in that it has a cache memory (962) for storing theblocks used by the nodes according to their addresses, and means formanaging, for an address used by one or more nodes, a presence vectorwith one presence indicator per node.
 13. Verification platformaccording to any of claims 7 through 12, characterized in that theprograms (90) are object-oriented and the emulator is structured as aset of classes that makes it possible to manage a collection ofexecution hypotheses for a transaction in a memory block of the softwaremodel, and also to manage transactions that are colliding, i.e.,concurrently using the same memory block.
 14. Verification platformaccording to any of claims 7 through 13, characterized in that thealgorithms of the programs (90) of the emulator perform the followingfunctions: generating predictions, eliminating predictions, readjustingincorrect predictions, reducing the number of valid hypotheses, andterminating collisions
 15. Verification platform according to any ofclaims 7 through 14, characterized in that it is used as an emulator ofa router circuit, a circuit with cache or a router circuit with cache.16. Verification platform according to any of claims 7 through 15 fortesting a software model of an integrated circuit on demand (ASIC),characterized in that it comprises an ASIC emulator (1) for controllinga comparator (23) provided for receiving values generated by thesoftware model of the ASIC circuit tested, upon reception of stimulisent by at least one stimuli generating circuit (21) storing the testprogram, an interface (11) for translating the stimuli from an advancedlanguage into a low level language corresponding to that of the softwaremodel, and means for validating the verification in case of thedetection of a collision by the comparator (23).
 17. Verificationplatform according to any of claims 7 through 16, characterized in thatthe means for selecting the response to stimuli that depend on thecomposition of the circuits tested are constituted by a model generatedby means for selecting functional models from a library, whichassociates with each of the models the responses to a given stimulus,the model corresponding to the composition of the circuit to be tested.18. Verification platform according to any of claims 7 through 17,characterized in that it includes means (7) for storing the responsesthus selected so as to create a test model (70) to be applied to thecircuit tested during the reception of stimuli.
 19. Verificationplatform according to any of claims 7 through 18, characterized in thateach transaction is constituted, at the level of each interface, by arequest packet and one or more associated response packets, wherein thevalues of the parameters and/or the transmission time constraints of thepackets can be forced from the functional test program executed by theemulator of the environment, which appropriately translates all of theseparameters during the transmission of the packets to the terminals ofthe software model of the design.
 20. Verification platform according toclaim 14, characterized in that the generation of predictions isperformed by the emulator of the circuit without having to obtainadditional information on the internal operation of the circuit underdesign.